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PREFACE 


The  Center  for  Information  Systems  Research  (CISR)  is  a 
research  center  of  the  M.I.T.  Sloan  School  of  Management. 

It  consists  of  a group  of  management  information  systems 
specialists,  including  faculty  members,  full-time  research 
staff,  and  student  research  assistants.  The  Center’s  general 
research  thrust  is  to  devise  better  means  for  designing, 
implementing,  and  maintaining  application  software, 
information  systems,  and  decision  support  systems. 

Within  the  context  of  the  research  effort  sponsored  by 
the  Naval  Electronics  Systems  Command  under  contract 
N00039-78-G-01 60 , CISR  has  proposed  to  conduct  basic 
research  on  a systematic  approach  to  the  early  phases  of 
complex  systems  design.  The  main  goal  of  this  work  is  the 
development  of  a well-defined  methodology  to  fill  the  gap 
between  system  requirements  specification  and  detailed 
system  design. 

The  research  being  performed  under  this  contract  builds 
directly  upon  results  stemming  from  previous  research 
carried  out  under  contract  N00039-77-C-0255.  The  main 
results  of  that  work  include  a basic  scheme  for  modelling  a 
set  of  design  problem  requirements,  techniques  for 
decomposing  the  requirements  set  to  form  a design  structure, 
and  guidelines  for  using  the  methodology  developed  from 
experience  gained  in  testing  it  on  a specific,  realistic 
design  problem. 

The  present  study  aims  to  extend  and  enhance  the 
previous  work,  primarily  through  efforts  in  the  following 
areas:  / 

1)  additional  testing  of  both  the  basic  methodology, 
and  proposed  extensions,  through  application  to  other 
realistic  design  problems; 

2)  investigation  of  alternative  methods  for  effectively 
coupling  this  methodology  together  with  the  preceding 
and  following  activities  in  the  systems  analysis  and 
design  cycle; 

3)  extensions  of  the  earlier  representational  scheme  to 
allow  modelling  of  additional  design-relevant 
information; 

4)  development  of  appropriate  graph  decomposition 
techniques  and  software  support  tools  for  testing  out 
the  proposed  extensions. 
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In  this  report,  a cost-benefit  analysis  of  the  new  techniques 
proposed  in  the  SDM  is  carried  out.  Three  models  are  developed 
which  attempt  to  capture,  in  functional  form,  the  important 
quantifiable  effects  that  ought  to  occur  as  a result  of  developing 
a system  based  on  an  optimal  partitioning  of  requirements.  Some 
numerical  examples  are  carried  out  to  illustrate  the  kind  of 
xesults  predicted  by  the  models  in  a realistic  design  scenario. 


EXECUTIVE  SUMMARY 


Complex  design  problems  are  characterized  by  a multiple 
of  competing  requirements.  System  designers  frequently  find 
the  scope  of  the  problem  beyond  their  conceputal  abilities, 
and  attempt  to  cope  with  this  difficulty  by  decomposing  the 
original  design  problem  into  smaller,  more  manageable  sub- 
problems. Functional  requirements  form  a key  interface  between 
the  users  of  a system  and  its  designers.  In  this  research 
effort,  a systematic  approach  has  been  proposed  for  the 
decomposition  of  the  overall  set  of  functional  requirement*, 
into  sub-problems  to  form  a design  structure  that  will  exhibit 
the  key  characteristics  of  good  design:  strong  coupling  within 
sub-problems,  and  weal  coupling  between  them. 

Recent  work  in  the  Systematic  Design  Methodology  project 
has  led  to  certain  extensions  to  the  basic  representational 
model  used  therein.  This  report  presents  a model-oriented 
normative  cost-benefit  of  the  Systematic  Design  Methodology. 

A set  of  three  sub-models,  pertaining  to  specification  impact, 
procedural  design  impact,  and  maintenance/modification  impact, 
are  derived.  These  models  attempt  to  capture,  in  functional 
form,  the  important  quantifiable  effects  - both  positive  and 
negative  - that  ought  to  occur  as  a result  of  developing  a 
system  based  on  an  optimal  partitioning  of  requirements. 

A numerical  example  is  also  discussed  to  better  illustrate 
the  kinds  of  results  predicted  by  the  models,  in  a realistic 
design  scenario. 
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The  Systematic  Design  Methodology  ( SDM)  is  a decision 
suppor t -or i ent ed  methodology  for  aiding  a software  designer 
in  determining  a good  design  architecture,  or  preliminary 
structuring,  of  the  functional  requirements  for  the  system 
under  design.  Various  aspects  of  the  methodology  itself 
have  been  described  elsewhere  ( (Andreu  78),  (Huff  and 
Madnick  78a, b),  (Huff  79)). 

In  this  report,  an  analysis  of  the  economic  impact  of 
SDM  is  presented.  This  analysis  is  eir.Dodied  in  a normative, 
conceptual  cost/benefit  model  (actually,  a set  of  three 
"sub-models").  The  model  attempts  to  represent,  in 
functional  form,  the  important  quantifiable  results  - both 
positive  and  negative  - that  would  be  extected  to  occu'  as  a 
result  of  adopting  and  using  SDM  in  software  design 
projects. 

Three  major  categories  of  beneficial  impact  are 
examined : 


a)  system  improvements  resulting  from  more  accurate  and 
appropriate  requirements  definition; 

b)  reduced  time  and  cost  for  detailed  design  and 
implementation  ("procedural  design")  resulting  from 
lower  communication  and  control  overhead  achievable 
through  an  improved  system  partitioning; 

c)  reduced  cost  for  making  later  modifications  to  the 
final  system,  resulting  from  reduced  inter-module 
"r ipple  effect . " 
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The  major  category  of  detremental  impact  addressed  here 
is  that  of' costs  (essentially  staff  time)  related  to  the 
carrying  out  of  the  SDM  activities  that  would  not  otherwise 
have  to  be  carried  out. 

While  there  are  potentially  mmy  other  categories  of 
costs  and  benefits  that  might  be  attributable  to  the  use  of 
a design  methodology  such  as  SDM,  it  is  believed  that  those 
identified  above  effectively  capture  the  first-order  impact. 
Other  potential  impacts  are  either  so  intangible  as  to  be 
unmodellable  quantitatively  (e.g.,  the  psychological  impact 
of  the  methodology  upon  the  system  designers),  or  are  of  a 
marginal  magnitude  relative  to  the  above  categories  (e.g., 
the  impact  of  SDM  on  the  code  debugging  process) . 

Calculations  for  a hypothetical  but  realistic  example 
are  carried  out  to  illustrate  the  nature  of  the  model 
further . 

1.1  Background  and  Related  Work. 

A number  of  authors  have  stressed  the  shifting  nature 
of  the  economics  of  computer-based  systems  (e.g.,  Dolotta, 
et . al . 76).  While  the  cost  of  computer  hardware,  notably 
logic  and  memory,  continues  to  fall  at  a rate  exceeding  20% 
per  year,  costs  of  software  development  are  moving  in  the 
opposite  direction,  nearly  as  fast  (Wasserman,  et . al . 78). 
The  dramatic  decrease  in  hardware  costs  is  related  to  the 
steep  learning  curve  for  micro-circuit  fabrication 


techniques,  and  to  the  economics  of  mass  production.  The 
very  first  Intel  8080  microprocessor  "cost"  about  $400 
million,  but  the  second  and  subsequent  copies  only  cost 
about  $0,271 

In  contrast,  pruductivity  improvements  in  the  systems 
design  and  programming  fields  have  come  much  mote  slowly. 

The  central  objective  of  the  ten-year-old  software 
engineering  field  is  to  develop  new  ways  of  "manufacturing" 
computer  software  systems  that  will  make  possible 
productivity  gains  comparable  to  those  being  achieved  in  the 
hardware  side  of  the  industry.  Nonetheless,  Boehm's 
analysis  of  software  production  for  the  Air  Force  (Boehm  73) 
indicates  that  typical  software  costs  for  major  systems  may 
approach  90%  of  the  total  system  (hardware  plus  software) 
cost  in  the  near  future,  as  shown  in  Figure  1.1. 

While  progress  in  software  engineering  has  been 
considerably  less  dramatic  than  in  the  hardware  area,  some 
important  advances  have  occurred.  There  is  also  a 
substantial  body  of  reserach  presently  under  way.  An 
important  outgrowth  of  these  facts,  not  yet  widely 
recognised,  is  the  need  for  software  "research  on  research": 
for  the  development  of  methodologies,  models,  techniques, 
etc.  for  eval uat i ng  the  successful  ness  of  t he  var ious  new 
appr oaches  to  software  design  and  development.  It  is  this 
need  that  the  present  study  addresses. 

The  literature  pertaining  directly  to  evaluation  of 
software  design/development  is  almost  nonexistant.  However, 
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some  studies  have  been  reported  in  related  areas.  Probably 
the  most  frequent  target  of  attention  has  been  productivity 
levels  within  the  programming  and  system  development 
activities.  Key  studies  include  those  of  Aron  (Aron  70), 
Wolverton  (Wolverton  74),  Putnam  (Putnam  78),  and  Walston 
and  Felix  (Walston  and  Felix  77).  These  studies  have 
basically  addressed  two  main  concerns: 

a)  what  is  programmer  (developer)  productivity,  and  how 
ought  it  be  measured? 

b)  what  factors  influence  productivity,  and  how? 

Walston  and  Felix,  for  example,  have  identified  and  ranked 
29  different  influencing  factors,  using  as  a productivity 
index  the  ratio  delivered  source  lines  of  code  to  total 
effort  in  man-months. 

Another  set  of  studies  have  addressed  the  system 
development  cycle.  Many  of  these  studies  present  normative 
frameworks,  extracted  from  the  authors'  experience;  for 
example,  (Cooper  78),  and  (Cave  and  Salisbury  78).  Others 
have  developed  models  of  the  system  development  process,  and 
use  them  to  try  to  better  understand  the  effects  of  various 
parameters  on  the  process,  and  to  serve  as  the  basis  for 
process  planning  and  control  methodologies  (e.g., 

Putnam  78) . 

A few  other  studies  address  specific  stages  of  the 
system  development  cycle  - for  example,  software  testing 
(Bate  and  Ligler  78),  or  system  maintenance  (Lientz, 
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et . al . 77).  Most  of  these  studies  also  attempt  to  identify 
the  important  independent  and  dependent  variables  of  the 
associated  process,  to  develop  models  relating  the  sets  of 
variables,  and  to  analyze  the  models  so  as  to  gain  further 
insight  into  the  nature  of  the  process. 

1.2  Evaluating  Design  Methodologies. 

As  stated  earlier,  there  is  a conspictuous  void  in  this 
literature,  namely,  studies  of  the  economic  and  other 
impacts  that  system  design  procedures  have  on  the 
development  cycle,  as  well  as  upon  the  containing 
organization.  A number  of  new  ideas  about  how  to  design 
software  effectively,  including  development  of  new 
conceptual  frameworks,  methodologies,  and  tools  for  design, 
have  recently  appeared.  Examples  of  these  include: 

- Structured  Design  (Stevens  et.  al . 74) 

- HIPO  (Stay  76) 

- SREM  (Davis  & Vick  77) 

- PSL/PSA  (Teichroew  & Bastarache  75) 

- SADT  (Ross  & Schomann  77)  . 

Most  of  these  schemes  are  quite  new,  however,  and  there  has 
been  almost  no  effectiveness,  or  cost/benef i t , evaluation 
studies  reported  for  them.  Reasons  for  this  include: 

- the  newness  of  the  methodologies  themselves  - there 
simply  hasn't  been  time  yet  to  undertake  serious 
evaluat ion; 
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- the  problem  of  what  to  evaluate  - i.e.,  measurement 
of  software  design 

- the  question  of  how  to  evaluate  - whether  via  models, 
empirical  testing,  user  attitude  surveys,  or  other 

means . 


Particular  questions  depena  upon  the  scheme  being 
evaluated.  However,  speaking  generally,  there  are  two  main 
approaches  that-  may  be  taken  to  design  methodology 
evaluation:  normative,  and  descriptive.  The  normative 

approach  may  be  described  as  follows.  In  theory,  a design 
methodology  X should  result  in  certain  kinds  of  design  and 
related  improvements,  and  incur  certain  costs.  The 
normative  evaluation  task  involves  developing  theoretical 
models  of  the  benefit  and  cost  impacts  of  the  methodology, 
then  to  explore  the  methodology's  potential  impact  on  the 
system  life  cycle  economics  using  the  models. 

The  descriptive  approach,  in  contrast,  is  concerned 
with  observing  and  studing  the  actual  use  of  methodology  X. 
In  other  words,  a real  (or  possibly  experimental)  system 
design  group  using  the  methodology  would  be  monitored  by  the 
evaluator,  with  the  objective  of  isolating  practical 
benefits  and  costs.  Much  of  the  gathered  data  would 
presumably  be  subjective,  based  on  opinions  and  judgments  of 
either  the  designers,  the  evaluator,  or  both.  Evaluation 
anal ys i s would  also  be  subjective  ("it  st  *med  to  be 
easier  ..."),  but  might  also  involve  standard  statistical 
testina  techniques. 
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A major  difficulty  with  descriptive  evaluation  would  be 
the  fact  that  such  studies  should  be  longitudinal  over  the 
entire  system  life  cycle  (typically,  ten  years  or  more),  as 
an  important  potential  benefit  of  most  design  methodologies 
should  be  easier  or  better  maintenance/modification 
activities.  This  effect  would  not  be  observable  during  the 
main  development  phase.  Consequently  the  time  to  conduct  a 
complete  study  would  be  rather  extensive,  and  the  costs 
quite  high.  This,  of  course,  is  yet  another  reason  for  the 
absence  of  such  studies. 

One  other  difficult  issue  regarding  evaluation  regards 
the  appropriate  base  case.  For  instance,  ought  design 
methodology  X be  evaluated  against  the  use  of  no  formal 
methodology,  or  against  the  use  of  some  other  methodology  Y. 
In  the  best  possible  world,  multiple  pairwise  comparisons 
would  be  carried  out,  between  X and  each  other  appropriate 
■competitor"  methodology.  This  approach  is,  clearly,  far 
too  expensive  and  resource-consuming  for  all  but  the 
wealthiest  of  organizations  (e.g.,  the  U.  S.  Department  of 
Defense)  to  pursue. 

1.3  Approach  to  be  Taken. 

The  present  study,  being  exploratory,  takes  the 
normative  approach,  and  addresses  the  "null"  base  case. 

That  is,  the  objective  of  this  report  is  to  identify  and 
model  the  key  benefit  and  cost  issues  that  ought  to  arise  as 
a result  of  using  the  Systematic  Design  Methodology. 


Evaluations  are  made  against  the  "no  methodology"  case  as  a 
base . 

The  key  arguments  and  results  of  this  analysis  are 
presented  in  the  next  three  ssctions.  Each  section 
addresses  a different  aspect  of  system  design  and 
development  that  the  Systematic  Derign  Methodology  impacts. 
In  each  case,  verbal  arguments  describing  the  nature  of,  and 
resources  underlying,  the  impact  category  are  given.  Then 
the  key  effects  in  each  case  are  represented  in  a functional 
model.  This  gives  rise  to  three  different  sub-models. 

A 

Section  5 is  devoted  to  "pulling  together"  the  sub-models, 
and  addresses  the  ways  in  which  they  interrelate.  Also,  a 
brief  hypothetical  example  illustrating  an  application  of 
the  models  is  given  there.  Section  6 contains  concluding 


comments . 
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2 . A System  Specif icat ion  Impact  Model . 

A common  refrain  from  system  developers,  when  asked  why 
their  systems  are  late,  over  budget,  or  even  complete 
failures,  has  been  that  they  were  u.iabl e t o secure  adequate 
user  par  t i ci pat i on  i n the  devel opment  pr  ocess . In  fact,  a 
survey  of  over  100  implementation  success  factor  studies  by 
Ginsberg  found  "user  participation"  to  be  the  single 
universal  factor  (Ginsberg  74). 

While  there  are  many  reasons  why  user  participation  is 
important  in  system  development,  perhaps  the  most  important 
reason  concerns  system  requirements  correctness  and 
completeness.  The  manifold  difficulty  of  eliciting  a user's 
complete  set  of  requirements  for  a target  system  has  been 
commented  upon  and  studied  by  a number  of  researchers  (e.g.. 
Bell  and  Thayer  76).  Others,  such  as  Boehm,  have  argued 
strongly  that  not  enough  time  is  spent  during  the  initial 
requirements  elicitation  and  verification  phase  of  the 
development  process.  Boehm  calculates  that  there  might  be 
as  much  as  a threefold  return  to  extra  effort  expended 
during  the  early  requirements  analysis  activities 
(Boehm  74) . 

One  of  the  important  impacts  of  SDM  concerns 
requirements  definition.  SDM  is  "driven"  by  the  set  of 
system  functional  requirements;  they  play  an  even  more 
central  and  crucial  role  in  the  SDM  than  in  the  usual  system 
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development  process.  This  comes  about  for  three  different 
reasons : 


a)  the  need  to  develop  requirements  in  statement  form, 
which  meet  the  SDM  criteria  ( un i f unct i onal i t y , 
implementation  independence,  common  level  of 
abstraction;  see  (Huff  and  Madnick  78a)); 


b)  performance  of  interdependency  analysis; 


c)  interpretation  of  a partitioning  of  requirements  as 
a system  architecture  (Andreu  78). 


Each  of  these  are  key  activities  within  the  Systematic 
Design  Methodology.  In  carrying  out  each  activity,  the 
attention  of  the  user  and  system  developer  are  jointly 
focussed,  in  a relatively  rigorous,  structured  way,  upon  the 
user-level  (non-procedural)  functional  specifications  of  the 
target  system.  It  is  through  this  "forced,"  structured 
focussing  of  attention  brought  about  by  the  need  to  carry 
out  the  steps  of  the  methodology  that  missing  requirements 
are  identified,  requirement  inconsistencies  spotted  and 
resolved,  and  requirement  statement  errors  discovered  and 
corrected . 

There  is  nothing  magical  about  why  this  should  occur. 

In  essence,  any  approach  that  necessitates  a careful,  step- 
by-step  analysis  of  requirements  in  such  a structured 
fashion  ought  to  achieve  many  of  these  same  results.  Within 
the  SDM  specifically,  however,  the  interdependency  analysis 
phase,  and  the  partitioning  interpretation  phase,  both 
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frequently  observed  to  occur  in  this  work.  Interdependency 
analysis  requires  the  designer  (and  user,  to  a lesser 
extent)  to  examine  requirement  reinforcements  and  tradeoffs 
on  a pairwise  basis,  thereby  bringing  to  light  requirement 
inconsistencies  and  errors  that  might  be  overlooked  if 
attention  were  not  directed  to  such  a specific  detail  level. 
Architectural  design  generation  involves  a general 
"reasonableness"  assessment  of  the  various  groupings  of 
requirements  produced  by  the  SDM  graph  decomposition,  and 
experience  has  shown  that  it  also  helps  to  highlight  missing 
requirements  and  requirement  errors  (Andreu  78). 

Prior  to  presenting  the  impact  model  for  requirements 
specification,  certain  underlying  assumptions  should  be 
discussed . 

Assumpt ion  K The  requirements  analysis  and  assessment 
activity  transpires  in  a series  of  identifiable  "passes." 
This  assumption  is  borne  out  empirically,  and  also  through  a 
consideration  of  the  SDM  operational  mechanisms.  For 
example,  a typical  SDM-oriented  development  effort  might 
follow  the  passes  shown  in  Table  2.1. 

Assumpt i on  2.  The  various  "passes"  tend  to  be  roughly 
equal  in  terms  of  expented  effort,  because  of  the  tendancy 
of  people  to  set  a series  of  fairly  easily  reachable  short- 
term goals  for  their  work.  From  this  it  follows  that  each 
pass  would  require  roughly  the  same  amount  of  elapsed  time. 
Time  is  a more  appropriate  metric  than  effort  (e.g.,  man- 
days),  as  the  requirement  assessment  tasks  tend  to  be 
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PASS 


1 

2 

3 


5 

6 


ACTIVITY 


Initial  problem  discussion. 

Formal  expresison  of  initial  requirements. 


fl 


Assessment  of  initial  requirements,  and 
generation  of  revised  requirements. 


Initial  interdependency  analysis  - identification 
of  additional  errors  and  inconsistencies. 


Discussion  and  generation  of  revised  requirements, 


Interdependency  analysis,  decomposition,  and 
determination  of  initial  architecture  - discovery 
of  more  errors,  missing  requirements,  etc. 


Final  revision  to  requirements. 


Table  2.1 
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somewhat  insensitive  to  effort  level.  The  key  reason  for 
this  is  that  preliminary  design  is  almost  always  the  product 
of  a small  number  of  individuals,  frequently  a single 
designer.  To  the  extent  that  most  design-related  decisions 
must  "funnel"  through  a very  small  cadre,  adding  additional 
help  doesn't  speed  things  up  very  much. 

Assumpt i on  3.  Conceptually  at  least,  there  exists  from 
the  outset  a "perfect"  requirements  specification  - one  that 
specifies  all  those  requirements  desired  by  the  system's 
eventual  users,  contains  no  errors,  is  completely 
consistent,  etc.  At  any  point  in  time,  this  perfect  set  of 
requirements  may  be  factored  into  three  subsets:  a set  of 
recognised  requirements,  a set  of  unrecognised  by  "knowable" 
requirements,  and  a set  of  unrecognised  and  "unknowable" 
requirements.  The  first  set  includes  those  requirements 
that  have  been  correctly  elicited.  The  second  set  includes 
requirements  waiting  to  be  elicited  (if  the  designers  or 
users  could  only  think  of  them,  they  would  recognise  them  as 
necessary),  as  well  as  requirements  corrections  to 
previously  elicited  but  incorrect  requirements.  The  third 
set  includes  those  requirements  and  corrections  that  at  this 
time  would  not  be  recognised  as  such  even  if  they  were 
brought  to  light. 

Assumpt ion  4.  During  requirements  analysis  step  i (see 
Table  2.1),  some  proportion  p„  of  the  remaining  knowable 

l 

requirements  "errors"  is  detected.  Here,  "errors"  should  be 
interpreted  broadly,  to  include  incorrect  statements. 


inconsistencies,  missing  requirements,  etc. 

The  argument  for  proportional  (as  opposed  to,  say, 
linear)  error  discovery  rate  follows  from  empirical 
observation:  Bell  and  Thayer's  experiments  indicate  that, 

essentially  no  matter  how  long  and  hard  requirements  are 
contemplated,  there  will  always  be  some  remaining  errors. 
Error  decline  seems  to  be  inherently  an  asymptotically 
decreasing  function  of  time  (i.e.,  of  number  of  "passes"). 
Also,  the  "satisficing"  phenomenon  first  explored  by  Cyert 
and  March  (Cyert  and  March  64)  supports  this  argument.  They 
pointed  out  and  supported  the  fact  that  people  generally  do 
not  strive  for  the  "very  best"  in  what  they  do,  but  rather 
generally  work  hard  enough  at  a given  task  to  obtain 
"satisfactory"  results,  then  rest  awhile.  In  the  present 
context,  for  instance,  a system  designer  would  probably  not 
(during  a given  pass)  seek  to  determine  every  last 
specification  error,  but  rather,  having  unearthed  a certain 
quantity  of  such  errors,  would  relax  the  intensity  of  his 
analysis.  A "satisfactory"  result  during  each  succeeding 
pass  would  include  a smaller  number  of  specification  errors 
detected  than  during  the  preceding  pass,  which  is  consistent 
with  the  assumption  of  some  proportion  of  errors  detected 
each  pass. 

It  will  be  assumed  for  simplicity  that  the  proportion  ^ 
for  pass  i is  more  or  less  constant  from  one  pass  to 
another.  We  will  then  take  pg  as  the  common  proportion  of 
remaining  errors  turned  up  during  each  pass.  The  nature  of 
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this  parameter  could  be  studied  empirically  in  particular 
design  situations. 

We  may  now  construct  a model  of  requirements  error 
reduction  based  on  the  foregoing  assumptions.  We  let 

3^0  * the  initial  level  of  knowable 
specification  errors,  and 

pe  * the  proportion  of  errors  detected 
each  pass, 

then  at  the  end  of  pass  1 an  additional  PeEkO  errors  will 

have  been  determined.  Remaining  errors  are  now  Ek0  n_Pe)  • 

Similarly,  at  the  end  of  pass  2,  remaining  errors  will  be 
2 

Ekod~Pe)  • In  general,  at  then  end  of  pass  i,  there  will 
be  knowable  errors  remaining. 

Now  if  we  take  the  unit  of  time  to  be  days,  and  assume 
each  pass  takes  about  dr  days,  then  we  may  write 

E*(t>  - ' 

where  E^ft)  * the  number  of  knowable  errors 

in  the  requirements  specification  at 
time  t. 


To  complete  the  error  reduction  model,  a few  additional 
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definitions  are 

required.  Let 

E 

u 

the  (constant)  number  of  unknowable 

requirements  errors; 

3 = 

r 

the  average  staffing  level  (both  users 

and  system  analysts)  incurred  during 

the  requirements  analysis  and 

preliminary  design  phase; 

c = 

r 

the  average  daily  cost  per  staff  member 

employed  in  this  activity  (in  dollars 

per  man-day) ; 

c = 

e 

the  average  cost  per  error  still 

remaining  in  the  requirements  set. 

The  final  item, 

ce , would  probably  be  difficult  to  determine 

directly  in  practice,  although  reasonable  surrogates  are 
available.  Boehm,  for  instance,  has  indicated  that  the  cost 
of  f jx *n9  errors  after  a system  has  been  built  to  run  as 
high  as  $4000  per  line  of  code.  Rough  estimates  of  c£  could 
be  obtained  empirically  by  asking  users  what  they  would  pay 
for  various  functions  determined  to  be  necessary  after  the 
fact . 

Using  the  foregoing  terminology,  three  equations  may  be 


written. 
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(1)  Cost  of  remaining  errors  at  time  t: 

cEm  - Ce[Eu  ♦ ] ...(2.1) 

(2)  Accumulated  cost  of  staff  devoted  to  SDM 
analysis  at  t ime  t : 

cS<t)  = cr  sr t ...(2.2) 

(3)  Total  cost  (cost  of  remaining  specification 
errors  plus  cost  of  staff  time): 

Cp(t)  = CE(t)  + Cs(t)  ...(2.3) 

A sketch  of  these  curves  is  given  in  Figure  2.1. 

From  this  it  is  possible  to  define  the  optimal  amount 
of  time,  t*  , that  ought  to  be  devoted  to  requirements 
analysi s : 

Total  cost  CT(t)  = Cg  ( t ) + Cs(t) 

‘ celE^  + EicO<1-Pe)drtl  4 srcr' 

Applying  calculus, 

dC  (t)  d t 

r = 'e^O^-Pe*  r <*r  ln(1‘Pe) 


dt 


+ sc 
r r 


0 


" 
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Solve  foe  t 


t*  = 


”srcr 

ln  d c E.  n In  ( 1-p  ) 
r e kO  e 


dr  ln  ( 1 - pe) 


The  locatijn  of  t*  is  also  shown  in  Figure  2.1. 

A reasonable  question  at  this  point  would  be,  why  we 
choose  to  include  only  the  foregoing  specification  error 
reduction  cost  factor  in  the  optimization  calculation.  The 
answer  is  that  it  is  the  only  payoff  factor  of  the  three 
sub-models  being  considered  here  that  is  significantly  time- 
dependent.  Put  differently,  assuming  SDM  is  used  a_t  all, 
the  payoffs  to  be  discussed  in  Sections  3 and  4 will,  in 
theory,  occur.  Only  the  payoff  due  to  specification  quality 
improvement  depends,  to  an  important  extent,  on  how  much 
time  is  spent  on  the  requirements  analysis  activity. 

The  error  reduction  sub-model  may  be  used  to  show  how 
SDM  would  improve  the  requirements  analysis  phase.  In 
general,  the  problem  with  requirements  analysis  has  been 
that,  due  to  its  unstructured  nature  and  due  to  a lack  of 
user  participation,  far  too  little  time  is  usually  spent  on 
it  in  the  course  of  a typical  systems  development  project. 

In  such  cases,  the  model's  operating  point  would  lie  well  to 
the  left  of  the  optimal  point  t*  for  CT(t).  As  shown  in 
Figure  2.1  SDM,  by  structuring  the  requirements  analysis 
activity  and  necessitating  additional  user  input,  would  tend 
to  move  the  operating  point  rightward.  The  value  CT(t*) 
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specifies  a lower  bound  on  the  associated  cost  reduction 
forthcoming  through  better  preliminary  system  specification. 

The  effective  dollar  benefit  from  the  requirements 
analysis  model  may  be  expressed  as 


= - n-Pe>  r ) 


. . . (2.') 


This  is  just  the  reflection  and  shift  of  the  cost-of- 
knowable-er ror s curve  from  Figure  2.1.  The  earlier  analysis 
may  be  confirmed  by  noting  that  the  optimal  operating  point 
t*  must  occur  at  the  point  where  marginal  cost  equals 
marginal  benefit.  From  before,  the  marginal  cost  is  just 
srcr*  Also»  the  marginal  benefit,  from  (2.4),  is 


dBr (t) 


“ceEkO(1"Pe)  r dr  ln(l-Pe) 


Equating  these  two  functions  leads  to  the  same  result  for  t* 
obtained  ear  1 ier  . 

The  value  of  net  benefit  provided  by  SDM  depends  on  the 
actual  pre-  and  post-SDM  operating  points  as  well  as  values 
of  the  other  parameters.  In  general,  at  operating  point  t, 
the  net  benefit  will  be 


NB  ( t ) 


BT(t)  - Cg(t) 


ce  ^kO  (1  " <1-Pe)drt)  - c^t 
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Finally,  if  we  assume  that  SDM  application  moves  the 
operating  point  from  t1  to  t,  the  net  improvement  in  cost 
will  be: 

I ( t*  ,t)  - NB  ( t ) - NB(t'  ) 

I 

, d t'  d t , 

* cehol  d-ife)  r - d-Pe>  r 1 
+ crsr(t'  - t)  . 

| 

1 

♦ 

These  relationships  are  sketched  in  Figure  2.2a,b. 
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3.  A System  Procedural  Development  Impact  Model . 

The  second  major  area  of  SDM  impact  concerns  the  time 
required  to  carry  out  the  procedural  development  (detailed 
design,  programming,  and  testing)  jhase  of  the  system  life 
cycle.  As  a number  of  authors  (e.g.,  Brooks  75,  Scott  and 
Simmons  75)  have  pointed  out,  a major  impediment  to  these 
activities  is  the  need  for  substantial  coordination  and 
communication  among  the  various  individuals  and  groups  of 
people  involved.  Indeed,  Brooks  has  cited  this  need  as  the 
reason  why  "men  and  months  are  not  inter changable"  in  system 
procedural  development  activities. 

There  are  two  primary  costs  that  arise  as  the  need  for 
coordination  and  communication  grows: 

a)  the  cost  of  additional  time  that  the  development 
staff  must  spend  in  these  activities,  which  detracts 
from  productive  development; 

b)  the  cost  of  additional  layer (s)  of  project 
management  overhead  needed  to  organize  and  manage 
the  inter-group  coordination  and  flows  of 
communicat ion . 

An  example  of  (a)  would  be  the  time  spent  in  intra-group 
meetings  devoted  to  ironing  out  issues  and  misunderstandings 
that  arise  from  interdependencies  between  the  various  tasks. 
An  example  of  (b)  would  be  the  resources  consumed  in  that 
portion  of  the  formal  project  management  process  devoted  to 
managing  intra-group  issues  (e.g.,  designing  a properly 


hi 
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sequenced  module  testing  plan). 

In  order  to  see  how  the  Systematic  Design  Methodology 
affects  the  communication  and  coordination  costs  of  system 
procedural  development,  we  briefly  review  some  central 
operational  aspects  of  SDM. 

3.1  SDM  Operational  Aspects. 

In  its  graph  partitioning  procedure,  SDM  groups 
together  system  functional  requirements  in  such  a way  as  to 
produce  weakly  connected  system  modules.  The  partitioning 
objective  function,  M,  consists  of  a difference  between  two 
terms: 

M = S - C, 

where  S is  the  sum  of  the  partitioned  subgraphs'  internal 
strengths,  and  C is  the  sum  of  the  coupling  between 
subgraphs.  More  specifically. 


n 


is  the  strength  of  module  i,  and  C^j  is  the  coupling 
between  modules  i and  j.  These  terms  are,  in  turn,  defined 
out  of  the  requirements  graph,  and  basically  involve  the 
normalized  richness  and  strength  of  the  requirement  links 
within  a module,  and  between  modules,  respectively  (see 
(Huff  79)  for  more  details).  While  seeking  to  maximize  M is 
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not  exactly  the  same  as  minimizing  inter-module  coupling, 
the  effects  are  closely  related.  Identifying  modules  of 
high  strength  tends  to  arrange  requirements  that  are  richly 
and  strongly  interconnected  together  in  the  same  module.  In 
a sense,  this  is  the  "dual"  objective  to  minimizing 
coupling,  i.e.,  to  arrange  modules  so  as  to  minimize 
interconnectedness  between  them.  Maximizing  S and 
minimizing  C thus  both  drive  toward  reducing  inter-module 
complexity,  in  one  case  by  "lumping"  complexity  inside 
module  boundaries,  in  the  other  case  by  drawing  module 
boundaries  so  as  to  keep  at  a minimum  the  extent  of 
complexity  that  is  "generated"  as  a result  of  the  module 
creation  process  itself. 

3.2  Model  Formulation. 

Now,  we  can  generalize  the  notion  of  a good 
requirements  partition  in  order  to  develop  a model  of  the 
communication/coordination  cost  impact.  We  define  a 
variable  D as  the  densi ty  of  module  interconnectedness.  A 
practical  measure  of  D could  be  the  value  of  system 
coupling,  C,  as  discussed  above.  Clearly,  the  impact  of  D 
upon  the  two  factors  identified  is  direct:  that  is,  as  D 
increases,  each  of  these  factors  will  increase  also.  The 
graph  in  Figure  3.1  shows  a hypothetical  set  of  curves  that 
depict  these  relationships. 

The  first  function,  relating  interconnection  density  to 
additional  "non-productive"  staff  time,  is  illustrated  as  a 
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nonlinear  function  that  "blows  up"  at  a certain  high  level 
of  density.  As  interconnection  density  D increases,  a 
larger  and  larger  proportion  of  staff  time  must  be  devoted 
to  the  coordination  and  communication  functions,  thereby 
shrinking  the  time  available  for  productive  development 
(given  some  initial  timetable)  towr.d  zero.  Conceptually  at 
least,  there  exists  some  (high)  level  of  problem  complexity, 
embodied  as  a large  D value,  such  that  the  coordination  and 
communication  needs  among  system  development  staff  use  up 
essentially  all  available  time. 

Evidence  for  this  phenomenon  is  cited  by  Haney 
(Haney  76)  in  the  context  of  development  and  maintenance  of 
a Honeywell  operating  system,  and  by  Belady  and  Lehman,  in 
the  context  of  the  IBM  OS/360  operating  system  (Belady  and 
Lehman  76) . 

There  is  an  interesting  parallel  between  the 
asymptotically  growing  need  for  coordination  and 
communication  discussed  above,  and  the  phenomenon  of 
"thrashing"  in  a demand-paged  virtual  memory  system.  In  the 
latter  case,  a "high  D value"  would  correspond  to  a lower 
level  of  reference  locality  for  a given  set  of  active 
processes.  A process  with  a low  level  of  reference  locality 
is  essentially  one  in  which  the  various  sub-parts  are 
"tightly  interconnected"  (in  terms  of  execution  references 
over  time),  much  like  a tightly  interconnected  set  of 
modules  in  a system  architecture  that  exhibits  high  D.  As 
locality  decreases  (D  increases),  the  system  overhead  costs 
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rise  in  a distinctly  nonlinear,  accelerating  fashion, 
similar  to  that  suggested  by  Figure  3.1. 

In  contrast  to  the  first  function,  the  relationship 
between  extra  development  management  overhead  and  D is 
hypothesized  to  be  one  of  linear  growth.  The  evidence  for 
this  comes  indirectly,  from  researchers  such  as  Wolverton 
(Wolverton  78),  who  suggest  that  such  overhead  grows 
linearly  with  project  size.  While  D does  not  necessarily 
purport  to  measure  size  directly,  it  is  reasonable  to  argue 
at  a first  approximation  that  a doubling  of 
interconnectedness  complexity  should  demand  more  or  less 
proportionally  equivalent  management  response  to  that 
demanded  from  the  size  doubling.  For  example,  it  requires 
some,  but  not  a disproportionate  amount,  of  additional 
project  management  time  to  convene  a meeting  for  four  team 
heads  as  between  two,  or  to  send  design  change  documentation 
to  four  teams  as  compared  to  two. 

A simple  functional  form  that  may  be  used  to  describe 
the  first  relationship  is 

Sp(D)  = I^/(D*  - D) 

where  D*  = the  density  value  at  which 

useful  staff  work  becomes  impossible, 

Kp  = a si t uat i onal 1 y dependent  parameter. 
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Sp (D)  = total  staff  time  required  for 

nonproductive  work  resulting  from  a level 
D of  logical  dependence  among  design 
sub-problems  (measured  in  man-days). 

Similarly,  the  functional  form  for  additional  project 
management  overhead  may  be  expressed  as 

Mp  ( D)  = LpD 

where  Lp  = a situat ionally  dependent  parameter, 

and  Mp ( D)  = extra  project  management  time  in 

procedural  development  necessitated  by 
a level  D of  logical  dependence  among 
design  sub-problems  (man-days) . 

It  is  not  suggested  that  these  functions  Sp(D)  and 
Mp(D)  are  fully  representative  for  all  values  of  D.  In 
particular,  D values  outside  the  range  [ 0 , D]  are  clearly 
inapplicable  in  this  model.  But  even  within  this  range, 
there  exists  a smaller  "relevant  range"  within  which  the 
functions  - especially  the  first  - are  really  hypothesized 
to  hold.  This  restricted  relevant  range  is  typified  in 
Figure  3.1  with  dashed  lines. 

The  first-order  impact  of  SDM  on  system  procedural 
development  time  may  then  be  expressed  in  terms  of  these 
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functions.  Basically,  the  effect  of  SDM  is  to  reduce  D for 
a given  project,  relative  to  what  it  would  be  if  SDM  were 
not  used.  Suppose  the  " wi t hout -SDM"  density  value  if  DQ , 
and  the  "with-SDM"  value  is  D,,^  < Dq  . Then  the  reduction 
in  additional  staff  time  would  be 
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K 


P 
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D*  -D 


SDM 


kp(do  - ° 
(D*  - DQ)  (D 


SDM* 

★ _ 


°SDM) 


and  the  reduction  in  additional  project  management  time 
would  be 


A ”p  ~ Kp  <D0  “ ^SDM  > 


Then,  if  Cgp  is  the  average  staff  cost  per  unit  of  time,  and 
Sip  *s  avera9e  project ' management  cost  per  unit  of  time,  the 
dollar  impact  of  SDM  on  development  may  be  expressed  as 


*p  ( D0  ' %DM  * CSp A Sp  + Sip  A Np 


A slightly  different  approach  to  measuring  Ip  would  be 
to  estimate  the  percentage  reduction  in  D that  might  occur 
as  a result  of  using  SDM.  If  experiments  were  to  indicate, 
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say,  lOOkp  percent  impact  on  D,  then  the  impact  on  costs  of 
using  SDM  could  be  written  as 


I 

P 


(Vdsdm> 


cspkpdo(1-V 

(D'-Dq) (d*-dsdm> 


+ CMPLMD0(1-kp) 


Finally,  it  may  be  appropriate  to  rewrite  this 
expression  based  on  DSDM  rather  than  D0 . If  we  let  lOOkp  be 
the  percentage  amount  by  which  D would  increase  were  SDM  not 
used  (assuming,  in  fact,  that  it  was  used),  then 


D0  = (1  + kp ) D, 


P'  SDM  ' 


and  the  cost  impact  expression  becomes 


C0  K k ' D_ 

I = --  SPPP  SDM + C L ( i+k ' i n 

D (D*-(l  + k')D__M)  (D*-Dor>l  ) Mp  p p;  SDM 


p SDM 


SDM' 


An  exercise  applying  the  procedural  development  impact 
model  is  given  in  Section  5. 
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4.  b System  Ma i nt enance/Mod i f i cat i on  Impact  Model . 

The  third  major  potential  area  of  impact  for  the 
Systematic  Design  Methodology  concerns  the  cost  of 
maintaining  - and,  especially,  modifying  - large  software 
systems.  The  rapidly  inflating  costs  of  system 
maintenance/modification  have  been  commented  upon  by 
numerous  authors  (e.g.,  (Boehm  75),  (Yau  78)).  The  need  to 
devise  ways  of  designing  and  constructing  systems  so  as  to 
reduce  the  maintenance  load  and  ease  the  costs  of  later 
modification  has  been  widely  recognised.  One  study,  for 
example,  has  estimated  the  production  cost  of  a software 
product  to  be  about  $75  per  line  of  code  (LOC) , while  the 
maintenance  cost  per  LOC  of  the  same  system  was  estimated  at 
$4000  (Boehm  75).  A variety  of  studies  have  indicated  that 
anywhere  from  40  to  80  percent  of  the  original  system 
development  cost  are  eventually  spent  on  "simple" 
maintenance  for  the  system;  when  all  post-implementation 
work  (including  non-trivial  modifications)  is  taken  into 
account  t lie  figure  rises  to  200  to  400  percent  (Thayer  77; 
Goetz  78).  At  any  rate,  while  often  exhibiting  rather  wide 
variances,  these  studies  unambiguously  indicate  that 
software  maintenance  and  modification  functions  are  assuming 
increasingly  high  profiles,  and  that  good  system  design 
practice  must  take  this  fact  fully  into  account. 

It  is  common  practice  to  differentiate  between 
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"maintenance"  and  "modification"  of  software  systems.  The 
former  term  refers  to  the  fairly  large  number  of  relatively 

i ; 

minor  changes,  bug  fixes  and  improvements  that  may  be  made 
to  a software  product  following  its  initial  release. 

Examples  include  patches  to  fix  minor  errors,  or  the 
addition  of  an  extra  report  to  a batch-oriented  DP  system. 

In  contrast,  software  modification  generally  refers  to 
more  significant  changes  made  to  the  system  - changes  that 
usually  entail  some  amount  of  redesign,  and  that  impact  most 
or  all  of  the  system's  users.  Major  changes  are  usually 
undertaken  to  add  significant  new  functions  to  the  system, 
or  to  improve  the  operation  of  a major  portion  of  the 

r 

system.  A prime  example  is  a new  release  of  a vendor's 
operating  system  (e.g.,  IBM's  OS/360). 

For  the  purpose  of  assessing  SDM' s impact,  we  will 
focus  primarily  on  the  modification  function.  More 
precisely,  we  will  be  concerned  with  those  changes  to  the 
user-visible  functions  provided  by  a particular  system  - 
changes  which  are  of  significant  enough  scope  that  impacts 
on  multiple  system  modules,  or  major  components,  are  likely. 

While  arguments  could  be  made  that  SDM  would  impact  both 
maintenance  and  modification  costs,  the  latter  impact  is 
almost  certainly  the  more  significant. 

The  primary  cause  of  system  modification  is  the 
recognition  on  the  part  of  the  user  clientele  for  changes  to 
the  functions  provided  by  the  system,  including  such  things 
as  addition  of  completely  new  functions,  major  enhancements 
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to  present  functions,  important  improvements  in  efficiency 
(response  time,  turnaround  time,  etc.),  availability, 
reliability,  etc.,  and  changes  to  fix  major  system  problems. 
One  primary  0]££harusm  through  which  system  modifications 
exert  their  apparently  disproportionately  high  economic 
impact  is  the  £2££ii£2  effect  that  such  changes  have  on  the 
system.  Changes  to  one  system  component  very  often  result 
in  the  need  to  make  subsidiary  changes  to  other  modules. 

The  propagation  of  these  indirect  changes  results  in 
telescoping  of  the  effect  of  the  original  change:  a single 
change  can  cause  other  changes,  which  can  in  turn  cause 
still  other  changes,  etc.  When  viewed  in  this  way,  the 
possibility  of  an  instability  phenomenon  - a single  change 
generating  a never-ending  sequence  of  subsidiary  changes  - 
presents  itself.  In  fact,  evidence  exists  that  such  an 
unstabe  situation  could  occur,  and  may  have  been  closely 
approached  in  certain  real-world  systems  (Haney  76;  Belady 
and  Lehman  76) . 

Since  the  changes  to  be  implemented  are  not  known  a 
priori,  it  is  not  possible  to  model  the  change  propagation 
effect  deterministically.  However,  some  simple 
probabilistic  arguments  provide  considerable  insight. 
Consider  two  system  modules,  M.  and  M,.  Using  the  SDM 
framework,  these  modules  are  "linked"  to  the  extent  that  the 
requirements  represented  within  one  module  are 
interdependent  with  the  requirements  represented  within  the 
other.  The  greater  the  number  of  such  interdependency  links 


relative  to  the  size  of  the  module,  the  greater  the 
liklihood  that  a change  to  one  or  more  of  the  requirements 
in  the  first  module  will  impact  (cause  a change  in)  the 
other  . 

We  define: 

rij  = the  number  of  requirements  represented  in 
Mi  that  link  to  requirements  in  M j ; 

Wij  = the  average  weight  on  the  requirement  links 
between  modules  and  Mj ; 

aij  = 3 sca*e  parameter,  discussed  further  below; 

= the  number  of  requirements  in  ; 

Pij  = the  probability  that  a change  to 
necessitates  a change  in  Mj . 

Then  we  propose  that,  to  a first  approximation, 

Pij  = aijrijwij/ni  * ...(4.1) 

This  relationship  presumes  that  most  changes  to  a module  are 
directed  toward  a single  functional  requirement  within  that 
module,  rarely  toward  multiple  requirements.  It  also 
assumes  that  changes  impact  each  contained  requirement  in  an 


equally  likely  manner.  Of  course,  neither  assumption  can  be 
strictly  true.  For  instance,  certain  requirements  may  be 
more  "central"  than  others,  and  thereby  stand  a relatively 
greater  chance  of  being  impacted.  Nonetheless,  the 
representation  above  is  a reasonable  first  approximation  to 
the  system  maintenance  error  propagation  phenomenon. 

The  expression  for  p^j  includes  a scaling  factor  o^j. 
This  factor  mainly  serves  to  quantify  the  effect  that  not 
all  changes  to  a function  within  a given  module  carry  over 
to  other  modules,  even  though  its  associated  requirements 
may  have  interdependencies  to  the  other  module.  While 
estimating  each  individually  would  be  difficult,  it  is 

quite  feasible  to  estimate  an  average  value,  say  a,  based  on 
the  maintenance  history  for  a given  design  group.  Such  an 
approach  is  followed  in  the  example  of  Section  5. 

According  to  the  above  formulation,  p—  4 Pj^  in 
general.  This  is  intuitively  correct  also:  for  example,  if 
n^  > n j , we  would  expect  there  to  be  a smaller  liklihood  of 
a change  in  impacting  than  vice  versa. 

From  the  above  arguments,  we  can  derive  the  "change 
propagation  liklihood  matrix",  P: 


p - iPtj]  • 

The  (i,j)th  entry  in  P is  the  probability  that  a change  to 
module  i necessitates  a further  (new)  change  to  module  j. 
The  change  propagation  liklihood  matrix  can  now  be  used  to 
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study  the  cost  impact  of  system  modifications.  Suppose  at 
some  point  in  time  a set  of  changes  to  the  system  is  being 
considered.  Let 


a^  - the  number  of  changes  to 

module  i being  considered. 


The  term  a may  be  thought  of  as  the  number  of  known  "bugs" 
in  module  i at  a point  in  time  (where  "bug"  is  to  be  broadly 
interpreted  - e.g.,  an  incompletely  implemented  function 
demanded  by  system  users  would  be  an  example  of  a "bug”). 
Also  let 


A = [a^  , * • • • , ] • 


A is  the  vector  of  planned  module  changes;  A will  be  termed 
a "revision"  to  the  system. 

Now,  the  originally  planned  changes  a,  , a.  , ...  , a 

12  n 

give  rise  to  additional  changes.  If,  for  instance,  there 
are  a^  planned  modifications  to  module  j,  this  will  generate 
a.  p • i expected  number  of  changes  to  module  1,  a • p • ~ changes 
to  module  2,  and  so  forth.  The  overall  expected  impact  of 
the  planned  changes  - the  average  number  of  "second-level" 
changes  - is  simply  the  matrix  product  AP.  The  first 
element  of  the  row  vector  AP  is  the  expected  number  of 
second-level  changes  to  module  1,  etc. 

The  second-level  changes  themselves  give  rise  to  yet 


1 
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additional  changes,  in  a corresponding  manner.  The  expected 
number  of  third-level  changes  to  each  module  can  be 
calculated  as 

(AP)P  = AP2. 

Conceptually,  this  telescoping  of  module  changes 
continues  ad  infinitum.  Mathematically,  the  total  expected 
number  of  changes  to  each  module  may  be  calculated  by 
summing  the  resulting  infinite  series, 

T = A + AP  + AP2  + AP3  + ... 

= A ( I 4 P +P2  +...)  ...(4.2) 

If  all  the  eigenvalues  of  the  matrix  P are  real  and  lie  in 
the  range  (-1,1),  then  a basic  result  in  matrix  algebra 
(Strang  77)  says  that  this  matrix  series  converges,  to  the 

V as  ue 


T = A ( I - Pf1  . ...  (4.3) 

Essentially,  expression  (4.3)  summarizes  the  ripple  effects 
that  occur  as  a result  of  modifications  to  modules  of  a 
large  system. 

This  basic  model  of  module  connectivity  can  be  now  used 
to  model  the  impact  of  SDM  on  system  maintenance.  First  of 
all,  the  essential  effect  of  SDM  decomposition  analysis  is 
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to  determine  an  optimal,  or  nearly  optimal,  decomposition  of 
the  system  requirements  with  respect  to  the  decomposition 
objective  function,  M.  As  discussed  in  Section  3,  this 
leads  to  requirements  partitionings  with  minimal  inter- 
partition  coupling. 

We  will  assume  that,  as  a first-order  result,  the 
coupling  between  requirements  represented  within  modules  i 
and  j is  reduced  by  a percentage  1006  —%  as  a result  of 
using  SDM.  Alternatively,  the  inter-module  liklihood  of 
change  propagation,  p , is  changed  to  a new  value 
p[j  ■ <5 1 j Pi  j . Thus  the  new  change  propagation  liklihood 
matrix  is  then 


SDM 


611P11 


5nlPnl 


6lnPln 


^ nnPnn 


If  we  further  assume  for  a moment  the  special  case  wherein 
all  6.  . are  equal  to  a common  value  6 , then  we  have 


PSDM 


= 6 P . 


Now,  if  the  series 


I 4 P 


+ P2  + 


. . . (4.4) 


converges,  then  so  does  the  series 
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I + P + P 

SDM  SDM 


The  proof  of  this  follows. 


. . . (4.5) 


Prj)of.  Since  we  assume  that  the  f'rst  series  converges,  the 
eigenvalues  of  P must  all  be  real  and  lie  in  the  range 
(-1,1).  Now,  the  eigenvalues  of  P are  the  values  of  A that 
solve  the  equation 


On  the  other  hand,  the  eigenvalues  of  PgDM  are  solutions 
to  the  equation 


|PSDM  XSDMT|  = 0 ' or 

I5  P “ ^DM1!  = 0 ' 

This  is  equivalent  to 

\s  (P  - %n|  - 0 , or 

| P - „I  | - 0 , ... (4.7| 

where  y = XSDM/  6 • But  equation  (4.7)  is  identical  to 

(4.6)  above.  Consequently,  A = AgDM/6  , or  ASDM  = A6 
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Since  |5|  < 1 and  |xj  < 1,  it  follows  that  |*SDM|  < 1 • But 
this  is  just  the  necessary  and  sufficient  condition  that 
series  (4.4)  above  converges. 


Therefore  it  is  clear  that  the  effect  of  reducing  all 
the  module  change  propagation  liklihood  values  can  only 
serve  to  reduce  the  ripple  effect  and  make  the  modification 
process  converge  faster. 

Now  we  define  the  average  cost  of  making  a change  to 
module  i as  c.  . The  vector  of  such  costs  is 

i 

C * {CL'  V c3 cn>  * 

The  total  cost  of  all  first-order  changes  may  then  be 
expressed  as 


AC. 


* Vl  * a2C2  + 


+ a c 
n n 


The  value  may  be  viewed  as  the  "optimistic"  cost  - i.e., 

the  cost  of  carrying  out  a revision  (set  of  changes)  to  a 

software  system  under  the  (naive)  assumption  that  P =0. 

Alternately,  if  the  ripple  effect  is  taken  into 

account,  the  total  cost  C of  the  revision  is  expressed  as 

T 


* 
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C„  = 


C1  + C2  + C3  + 


AC  + APC  + AP  C + 


= A ( I + P + P 
= A ( I - P)_1C 


)C 


...(•!.  8 ) 


This  view  of  the  cost  of  the  revision  A might  be  termed  the 
"realistic"  cost,  as  opposed  to  the  foregoing  "optimistic" 
cost,  in  that  it  takes  into  account  the  ripple  effect. 

Finally,  the  "realistic"  cost  of  the  revision  A under 
the  assumption  that  SDM  was  employed  would  be 

Ct(SDM)  - »(I  - p^r'c  , 

where  PgDM  = ( ) = (5ijPij)  as  defined  earlier. 

Hence  the  cost  reduction  for  the  revision  A that  could 
be  attributed  to  SDM  would  be: 


Sr 


Ct(SDM) 

= A ( I - P)_1c 
= A [ (I  - P)_: 
= ABC 


A(I 
(I  - 


- P 


»-l 


SDM 

p r1] 

SDM  J 


. . . (4.9) 


where  we  define  B = (I  - P)-1  - (I  - P„^w  )-1  . 

SDM 

Some  insight  can  be  gained  into  the  nature  of  this 
function  by  considering  some  special  cases.  Suppose  the 
change  propagation  liklihood  value  p^j  was 


k 
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P 


P.  . 

ID 


if  i = j , and 


ot  her  wi se . 


Then  a single  modification  made  to  any  one  module  results  in 
a total  number  of  expected  changes  to  that  module  of 

1 -t  p.  + p2  + ...  * 1/(1  - p.  ) 

ii  i 

For  instance,  if  there  is  a 10%  chance  of  a change  in 

module  i resulting  in  another  change  in  the  same  module, 

then  = 0.10,  and  the  expected  number  of  changes  resulting 

from  a single  change  to  module  i would  be  1.1111...  . 

Now  assume  that  there  are  n modules,  and  p . = p for 

i-D 

all  i,j  . That  is,  the  liklihood  of  change  propagation 
between  any  pair  of  modules  if  100p%.  Then  a single 
original  change  to  one  module  generates  np  expected  second- 
order  changes,  each  of  which  generates  another  np  expected 
third-order  changes,  etc.  The  total  number  of  changes  is 
then 

1 + np  + (np)2  + (np)3  + ...  = 1/(1  - np)  . 


This  expression  reflects  the  impact  of  both  change 
propagation  liklihood  p and  system  size,  in  terms  of  number 
of  modules,  n. 

There  is  an  asymptotic  limit  at  the  point  np  = 1,  or 


p = 1/n,  as  shown  in  Figure  4.1.  This  limit  represents  the 
point  at  which  the  system  is  large  enough  and  interconnected 
enough  that  a single  change  will  ripple  forever  throughout 
the  system  - the  number  of  generated  changes  "blows  up." 

This  blow-up  phenomenon  is  closely  related  to  the  point 
D = D*  discussed  in  the  Procedural  Development  Model  of 
Section  3. 

The  foregoing  analysis  indicates  the  large  payoff  to 
reducing  the  degree  of  interconnection  of  a system's  design, 
even  by  a small  amount.  Haney  (Haney  75)  points  out  that 
informal  experiments  with  the  Xerox  Universal  Timesharing 
System  showed  each  change  to  be  causing  approximately  10 
additional  changes.  This  system  had  about  22  major  modules, 
so  that 


1/(1  - np)  = 1/(1  - 22p)  = 10  + 1 = 11  . 

Hence  p = 0.04  . If  the  interconnection  propagation 
liklihood  could  have  been  reduced  by  25%,  to  p = 0.03,  the 
number  of  additional  changes  following  a single  change  would 
have  dropped  from  11  to  3J  This  would  obviously  lead  to 
substantial  savings  in  maintenance  costs. 

Additional  illustration  and  siscussion  of  this  and  the 
earlier  models  is  given  in  the  following  section. 
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5 . An  Illustration. 


5.1  Rocapi t ul at i on . 

In  the  previous  three  sections,  three  different  models, 
one  for  each  of  the  major  impact  areas  of  the  Systematic 
Design  Methodology,  were  described.  To  recap  briefly,  the 
three  areas  are: 


a)  system  specification  - correctly  identifying  and 
stating  as  many  of  the  "knowable"  functional 
requirements  as  possible,  within  the  constraints  of 
time  and  manpower  available; 

b)  system  procedural  development  - carrying  out  the 
detailed  design,  coding,  and  testing  of  the  system, 
together  with  the  accompanying  load  of  coordination 
and  communication  overhead  among  members  of  the 
development  team(s); 

c)  system  mai ntenance/modi f icat ion  - making  necessary 
or  requested  alterations  to  the  functions  provided 
by  the  system  - correcting  errors,  adding  new 
functions,  etc.  - while  simultaneously  making  sure 
that  all  secondary,  tertiary,  etc.  changes  to  other 
system  modules  are  also  identified  and  carried  out. 


The  three  models  developed  in  the  previous  sections  are 
different  from  each  other  in  certain  ways.  For  one  thing, 
the  first  two  are  deterministic,  while  the  third  contains 
probabilistic  elements.  Also,  in  the  first  model,  time  is 
the  key  independent  variable,  whereas  in  the  second  the 
focus  is  on  the  density  of  module  interconnectedness,  and  in 
the  third,  the  number  of  changes  to  be  made  to  different 
system  modules  together  with  the  probabilities  of  change 
propagation.  All  three  models  attempt  to  capture  the 
effects  of  the  modelled  independent  variables  and  parameters 
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on  cost  - i.e.,  various  components  of  cost  are  the  dependent 
variables  in  the  different  models. 


5.2  Example  Calculation. 

In  order  to  further  illustrate  the  functioning  of  the 
SDM  impact  models,  a sample  calculation  for  a hypothetical 
system  is  presented  in  this  section. 

Con*,  der  a system  design  problem  with  the  following 
character i st ics : 

a)  There  are  200  functional  requirements  making  up  fhe 
system's  user-level  functional  specifications; 

b)  The  preliminary  design  has  factored  the  requirements 
into  10  partitions,  each  containing  an  average  of  20 
r equi r ement  s . 

c)  In  the  base  case  (pre-SDM)  partitioning,  on  the 
average,  any  given  functional  requirement  is 
interdependent  with  10  other  requirements.  The 
average  interdependency  strength  factor  is  0.60. 

We  will  consider  each  of  the  three  impact  models  in 

turn. 

5.2.1  Specification  Impact  (Model  1). 

To  carry  out  computations  using  this  model,  we  need 
numerical  values  for  the  terms  Ek0 , E^, , pe , dr , sr , cr , and 
ce . The  following  values  will  be  taken  as  reasonable 
estimates  for  present-day  technology  and  salary  scales: 
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PARAMETER 

VALUE 

E,  „ 

50 

kO 

Eu 

20 

Pe 

0.2 

d 

r 

3 

s 

r 

20 

c 

r 

100 

c 

e 

1000 

With  these  values,  the  equat 


UNITS 

knowable  errors  (initial  level) 
unknowable  errors 
(unitless  - proportion  of 
errors  detected  per  pass) 

? ays/pass 

man-days/day  (average  staff 
level ) 

dol 1 ar  s/man-day 
dol  1 ar  s/er  r or 
ions  for  model  1 are 


cs(t) 


set  = 2000t 

r r 


.. . (5.1) 


Ss<‘>  ■ ce[Eu  + W1  ' Pe»drt| 

= 1000[ 20  + 50 (1  - 0 . 2) 3t] 


. . . (5.2) 


cT(t)  = C (t)  + CE(t) 


. . . (5.3) 


These  three  equations  are  sketched  in  Figure  5.1 

Further  calculations  show  the  optimal  time  spent  in  SDM 


analysis  is 


In  l 


-s  c 
r r 


drCcEkO  ln(1-Pe} 
dr  ln[l-pe] 


] 


= 5.2  days  . 


. . . (5.4) 
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Thus,  approximately  two  SDM  passes  are  suggested  as  best  for 
minimizing  total  cost  (requirements  errors  plus  staff  time). 
The  optimal  t value  is  also  indicated  on  the  sketch  in 
Figure  5.1  . 

The  resulting  cost  of  analysis  plus  remaining 
requirements  errors  is  calculated  as  approximately  $26,700 
at  t = t* . The  net  improvement  at  t = t*  as  compared  with 
t = 0 (no  SDM  analysis  done)  is 

K 0,f)  - cely  [ 1 - U-P^V  ] 4 crsrt 

= 50000  ( . 969)  + 10400  = 58860 


5.2.2  Procedural  Development  Impact  (Model  2). 

If  we  now  turn  to  examine  the  second  model  for  this 
problem,  we  see  that  we  need  estimates  for  the  following 
terms:  D*,  Kp,  Lp,  DSDM,  D Q,  Cgp,  and  CMp.  Consider  first 

the  D terms.  In  Section  3 we  did  not  constrain  the  units  of 
D specifically,  but  merely  defined  D to  be  a measure  of 
module  interconnectedness.  For  the  present  purposes  we  will 
take  D to  be  the  per-module  sum  of  the  interdependency 
weights  on  all  the  external  ( i nt er -modul e)  requirement 
interdependencies.  This  is  an  intuitively  easy  value  to 
work  with,  and  demands  no  further  assumptions  regarding  the 
structure  of  the  requirements  graph  (e.g.,  module  coupling 
est imates) . 
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Now,  using  the  data  given  earlier,  each  of  the  ten 
modules  contains  (an  average  of)  20  requirements.  Each 
requirement  links  to  ten  other  extra-module  requirements, 
with  an  average  link  weight  of  0.60.  Therefore, 

Dq  = (20  requirements/module)  x (10  1 inks/r equireme.it)  x 
(0.60  strength  units/link). 

= 120  (strength  units/module)  . 

For  illustrative  purposes,  we  will  now  assume  that  SDM 
analysis  produces  a superior  partitioning  of  the 
requirements,  and  results  in  each  requirement  linking  to  six 
other  extra-module  requirements,  with  an  average  link  weight 
of  0.40.  Therefore 

D = (20  req. /module) x (6  links/req.)x 

SDM 

(0.4  strength  units/link) 

= 48  strength  units/module. 


Next,  we  need  an  estimate  of  D *.  A possible  approach 
to  estimating  the  complexity  limit  D*  would  be  to  consider 
the  worst  possible  case  - i.e.,  the  case  in  which  every 
requirement  linked  to  every  other  extra-module  requirement 
with  a maximum  weight.  This  would  give  rise  to  a D*  value 
of  (20) x ( 9x20) x ( 1 ) = 3600.  However,  such  an  extreme  case  is 
clearly  not  representative  of  realistic  settings.  At  issue 
regarding  D*  is  the  question  of  how  complex,  in  terms  of 


module  interrelationships,  a real  design  scenario  needs  to 
be  before  essentially  all  useful  effort  ceases  - i.e., 
before  "thrashing"  fully  sets  in.  To  draw  on  the  virtual 
memo- y analogy  again,  thrashing  can  completely  bcttle  up  a 
virtual  storage  computer  system  long  before  the  theoretical 
worst  case  (a  page  fault,  or  multiple  page  faults,  on  every 
new  instruction  - see  (Madnick  and  Donovan  76,  page  498)) 
occurs.  Therefore,  for  present  purposes  let  us  assume  that 
the  "thrashing"  level  of  D is  D*  = 200.  In  other  words,  we 
will  assume  here  that,  if  inter-module  complexity  were 
roughly  twice  as  high  as  in  the  base  design  case,  almost  all 
designer  time  would  be  spent  in  coordination  and 
communication,  with  little  or  no  project  headway  possible. 

To  calculate  the  parameter  Kp  , we  would  need  to 
estimate  the  per-man  project  overhead  under  D = 0.  This 
corresponds  to  each  module  design  being  independent  of  all 
others.  Under  such  conditions,  there  would  still  be  some 
basic  level  of  general  coordination  and  planning  overhead  to 
be  incurred.  For  argument's  sake  we  take  this  to  be  50  days 
per  man  over  the  duration  of  the  project. 

Under  this  assumption,  at  D = 0 , we  have 

S (0)  = Kp/D*  = 50  days/man,  so 

^ = 50(200)  = 10,000. 


The  units  of  Kp  are  (staff  days/man) x (weight  units/module). 
Finally  we  will  estimate  by  assuming  that  under  the 
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base  case  design  about  100  project  management  man-days  would 
be  required.  Therefore, 


L = 100/120  = 0.83  . 

P 


The  units  ;f  are  (management  days/man) x (modul es/weight 
unit ) . 

We  take  the  per-diem  staff  and  project  management  costs 
as  before  to  be 

Cgp  = 100  dollars/man-day,  and 
C * 150  dollars/man-day  . 

With  the  foregoing  data,  the  model's  equations  are: 


S (D) 
P 


Mp(D) 


Kp/(D*  - D)  = 10000/(200  - D) 

... (5.4) 


LpD  = 0.83D 


. . . (5.5) 


1 


The  cost  impact  curves  for  Model  2 are  given  in 

Figure  5.2.  The  points  D and  D are  indicated,  as  are 

U SDM 

the  associated  cost  impacts. 


The  cost  savings  under  the  foregoing  assumptions  and 
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estimates  turn  out  to  be: 


I 

P 


S 

P 


+ 


M 


P 


100 (10000) (120-48) 
(200-120) (20Q-48) 


150 ( . 83) (120-48) 


= 5921  + 8964  = $14,885 

Therefore,  use  of  the  design  methodology  reduces  impact  of 
development  overhead  under  the  given  assumptions  by  about 
15,000  dollars. 


5.2.3  Modification/maintenance  Impact  (Model  3). 

Now  we  turn  to  the  third  model,  impact  on 
modification/maintenance.  This  model,  being  probabilistic 
and  matrix-oriented,  is  computationally  somewhat  more 
compl ex . 

In  the  present  case,  if  we  consider  a typical  module 
pair,  using  the  information  provided  earlier,  we  find  that 
equation  (4.1)  becomes 


Pij  = Clij10  ( «6)  /20  = ( 0 . 3)  ai  j , if*  j . 

Now  we  will  estimate  the  a — scale  factor  at  0.25,  for  all 
i,j.  Consequently  we  take  each 

Pi;j  = (0.3)  (0.25)ct  = 0.075  (i  j*  j)  . 

Also,  we  will  estimate  the  on-diagonal  probability  to 
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be  twice  this  value,  0.150.  Thus  the  matrix  P has  the  form 

. 075  .075  075 

. 1 5 .075  075 

.075  . 075  15 

Of  course,  in  a more  realistic  situation  the  P matrix  would 
be  sparser;  there  would  be  a number  of  module  pairs  with  no 
interdependencies.  The  above  calculation  is  quite 
reasonable  for  illustrative  purposes. 

To  continue  the  example,  we  will  also  estimate  the 
6-factors  as 


P = 


.15 

.075 


.075 


6 = 0.67  . 

That  is,  we  assume  that  partitioning  the  requirements  via 
SDM  reduces  the  inter-module  change  propagation 
probabilities  by  1/3.  Thus  the  new  P matrix  becomes: 


P 


SDM 


0 . 67 (P) 


.10 

.05 

.05 

05 

p 

.05 

.10 

.05 

05 

SDM 

0 

0 

.05 

.05 

.05 

....  .10 

.05 
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A check  shows  that  both  P and  P_,  do  have  all  their 

SDM 

eigenvalues  in  the  (-1,1)  range,  so  their  series  do 
converge.  The  values  of  these  matrices  are  given  in 
Table  5.1. 

To  complete  the  example  using  Model  3,  let  us  assume 
that  each  module  will  require  two  significant  modifications 
over  the  lifetime  of  the  system.  Therefore  we  let 

A = [ 3^ i a ^ > ...  = ( 2 , 2,  2 , ••«,  2]  . 

Also,  we  will  assume  that  the  average  cost  for  modifying  a 
module  is  1000  dollars,  i.e., 

C = [c.  , c_  , ...  , c ] = [ 1000  , 1000  , ...,  1000] 

12  n 

Under  these  assumptions,  the  "optimistic"  modification 
cost  is 


C = AC  = $40,000 

The  "realistic"  cost  for  the  given  revision  is, 
however , 


C T = A (I  - P f1  C 
*=  $109,841  . 


Hence  the  SDM  modification  cost  reduction  for  this  revision 


1.544  . 463  . 463  463 

. 463  1.544  . 463  463 

.463  .463  . 463  1.544 


(a) 


p + P + P + 

SDM  SDM  SDM 


1.170  .117  .117  117 

.117  1.170  .117  117 

.117  .117  .117  1.170 


Table  5 . 1 
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would  be 

ABC 

= 2(1  000)1  B Ifc 

where  B = (I  - P )-1  - (I  - P )_1 
0 SDM 

and  1 = [1  1 1 ...  1 ] (10  elements). 

Calculations  show  that 

ABC  = 2(1000)  1 B l1 


= 2000  [1  1 ...  1] 

* 375  . 346  . 346  ...  . 346 

1 " 

.346  .375  .346  ...  .346 

1 

.346  .346  .346  ...  .375 

1 

i_  — 

= 69841  . 

By  this  estimate,  SDM  partitioning  would  lead  to  an 
estimated  cost  savings  over  the  modification  life  of  the 
system  of  nearly  $70,000. 

5.3  Summary  of  Illustration. 

The  results  of  the  calculations  in  the  foregoing 
example  are  summarized  in  the  table  below. 
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ITEM 

Optimal  SDM  Analysis  Time 
Cost  of  Analysis  (at  t = t* ) 
Specification  Error  Reduction 
Benef  i t (at  t = t*,  as 
compared  to  t = 0) 

Base  Case  Module  Interconnected- 
ness (Dq) 

SDM  Module  Interconnectedness  (DgDM) 

Development  Benefit 

j 

Modification  "Ripple  Effect" 

' Benefit 

Total  SDM  Benefit 
Total  SDM  Cost 


RESULT 
5.2  days 
$10,400 


$58,860 


120 

48 

$14  ,885 


$69,841 


$143,586 

$10,400 


Net  SDM  Benefit  (this  example)  $133,186 


Table  5.2 


I 


4 


* 


L 


I 
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6.  Conclusions. 


The  models  presented  and  discussed  hf~re  are  in  many 
ways  crude  and  of  limited  scope.  But,  as  we  pointed  out 
earlier,  there  is  no  other  published  work  on  modelling  the 
impacts  of  design  methodologies  at  all.  This  preliminary 
effort  at  least  illustrates  the  feasibility  for  improving 
understanding  of  the  economic  potential  of  improved 
functional  design  partitionings  and  other  related  aspects  of 
systems  design. 

A number  of  issues  were  raised  but  not  completely 
answered  in  this  report.  Some  of  the  most  important  are: 


- how  to  accurately  determine  the  various  parameters  of 
such  models; 

- how  to  better  verify  the  correctness  of  the  models' 
functional  forms; 

- how  to  make  effective  use  of  such  models  - e.g.,  what 
can  be  learned  from  sensitivity  analysis  or 
parametric  variation? 

- how  to  improve  the  models  - e.g.,  perhaps  we  ought  to 
be  looking  at  different  aspects;  perhaps  some  of  the 
"second-order"  effects  are  really  more  important  than 
they  were  assumed  to  be  here. 


These  and  other  questions  will  be  studied  in  future 


invest igat ions. 
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